Enter your search text in the box above

Select a result to preview

Rust 需要规范，但现在不需要外部治理型标准

上一篇《在 Borrow Checker 之前，Rust 先做了一场系统级 Erlang 的梦》讨论的是 Rust 如何在早期探索中放弃一部分自己，最后收敛到所有权、借用与零成本抽象。那段历史留下了一个很 Rust 的习惯：先允许实现和真实使用暴露问题，等设计成熟，再把它变成稳定承诺。

这次的问题正好落在另一端：当一门语言已经进入操作系统、汽车和安全关键软件，它还能一直靠“编译器就是答案”吗？

不能。Rust 需要一份官方、完整、随版本维护的规范。

但我不赞成现在把 Rust 语言的最终规范权交给一个可以独立于 Rust Project 演进的外部标准组织。Rust 缺的是可审计的语言定义，不是另一套拥有最终解释权的语言治理。

这两个判断并不冲突。冲突只会发生在我们把 specification 和 standard 当成同一个词的时候。

五个经常被混用的概念

**规范（specification）**回答：什么文本是合法的 Rust 程序，合法程序具有什么含义？

它要覆盖静态语义和动态语义，包括类型检查、求值、内存与并发行为、未定义行为，以及 unsafe 代码可以依赖的边界。Rust 规范团队在 2023 年公布的愿景 中又区分了两类内容：一类描述某个 Rust 版本事实上怎样工作，另一类规定未来实现不能越过的边界。前者服务复现与审计，后者才构成承诺。

**标准（standard）**多了一层制度安排。它通常有明确的维护组织、参与和表决规则、版本、合规边界。外部标准组织可以只给上游项目做版本化快照，也可以与上游协同维护，还可以获得独立修改规范的权力。本文反对的是最后一种在当前 Rust 上过早发生；不能把所有标准化模式都偷换成“ISO 接管语言”。

官方主实现是代码。rustc 是 Rust Project 的官方编译器，也是生态中的事实行为基准，但它没有被正式指定为裁定其他实现是否合规的 reference implementation。这个区别很重要：rustc 的输出不会因为来自官方编译器就自动覆盖规范文本。实现会有 bug，也会保留一些从未承诺的偶然行为。

**稳定性承诺（stability promise）**回答：哪些已经稳定的源码、API 和行为在升级后应继续兼容，哪些例外可以被修正？Rust 的承诺很强，但不是“任何旧代码永不失效”。RFC 1122 允许在谨慎评估后修复编译器 bug 和 soundness 问题，也承认某些未指定行为本来就不在承诺内。

**认证（certification）与工具资格（tool qualification）**不是同一层面的结论。前者通常针对产品或开发过程是否满足行业标准，后者评估特定工具在限定用途下是否具备足够可信度。Ferrocene 为明确列出的版本、目标、组件和使用约束提供工具资格材料；TÜV SÜD 的 qualification 只适用于相应安全标准和限定配置。语言规范是证据链的一部分，不等于“Rust 语言已经获证”，也不等于任意 Rust 工具链都能用于同一等级的系统。

规范定义语言，标准安排共同维护与合规，实现负责执行，稳定性约束升级，认证提供证据。Rust 现在最急迫的缺口在第一项。

Rust 已经解决了语言如何变化的问题

Mara Bos 在 Do we need a "Rust Standard"? 中的核心判断是对的：Rust 需要准确规范，却不必因此把语言演进移交给标准组织。

Rust Reference 还不是完整规范，标准库文档也只承担了部分规范职能。到了 unsafe、别名规则、内存模型和并发语义，答案分散在 Reference、Unsafe Code Guidelines、Miri、rustc 行为和各团队决议中。这对普通应用开发影响未必明显，对编译器作者、unsafe 库作者和认证团队却很麻烦。

文档不完整，不等于 Rust 没有演进秩序。较大的语言改动通常先经过 RFC 与公开讨论，由负责团队形成共识。RFC 获批不保证功能最终实现，更不保证一定稳定。实现进入 nightly 后仍由 feature gate 隔离，真实试用可能暴露原设计的问题；若要偏离既有决定，需要回到 tracking issue、设计讨论和团队审批。成熟的语言特性再经过稳定化流程进入 stable。

几套机制分别处理不同问题：

这套模式的价值不在于它比委员会更“互联网”，而在于它把实验和稳定承诺分成两个阶段。实现反馈可以改变设计，stable 用户又不必承担 nightly 的全部试错成本。

因此，Rust 当前并不缺一套决定新特性如何进入语言的流程。真正的欠账是：已经形成的决定没有被持续、完整地整理成权威语义文本。

rustc 何时不再是足够好的答案

对大多数应用开发者，stable 编译器、标准库文档、CI 和生态兼容性实践通常够用。代码能编译，测试能通过，升级前再跑一轮验证，这个反馈回路直接而有效。

安全关键系统不接受同样的证据标准。审查者需要从源码行为追到语言规则，再追到编译器测试、工具资格和具体配置。假如一段 unsafe 代码出错，团队必须判断它违反了哪条规则，还是编译器偏离了规则。没有权威规范，这条追踪链会在最需要确定性的地方断掉。

替代实现也会碰到同一个问题。若 rustc 是唯一可用的行为基准，另一个编译器想兼容 Rust，最保险的办法就是复刻 rustc，连偶然细节和 bug 都可能一起复制。规范能把“Rust 保证什么”与“rustc 当前做什么”分开。

不过，官方规范并不自动等于多实现标准。RFC 3355 明确把“定义何为合规 Rust 编译器”列为非目标。它首先要把 Rust 程序及其行为说明白，而不是马上建立编译器认证体系。这是一个克制但合理的顺序：先确定语言语义，再决定是否需要独立实现之间的合规测试和裁决制度。

采购与监管会形成第三种压力。外部标准可以提供跨供应商共享的版本化指称，方便合同和法规引用；合同仍然必须写清标准版本、实现、目标、扩展、配置和认证范围，单写一句“符合 ISO Rust”并不会神奇地消除工程细节。

截至目前，Rust 已经跨过“必须有完整规范”的门槛，还没有明显跨过“必须让外部组织拥有最终规范权”的门槛。

FLS 已于 2025 年由 Rust Project 接收

这件事的进展比 2022 年原文写作时更快。

Ferrocene Language Specification（FLS）最初由 Ferrous Systems 为 Ferrocene 工具链编写。2025 年 3 月，Rust Project 正式接收了 FLS。所以今天必须把两件事分开说：Ferrocene 工具链仍是 upstream Rust 下游的产品；FLS 虽然起源于 Ferrocene，却已经进入 Rust Project 的规范工作。

FLS 和 Rust Reference 目前仍是两份独立文档。官方接收公告明确表示，Reference 的地位没有因此改变，项目会继续改进 Reference，同时寻找两份文档互相支持、长期更紧密结合的办法。2025 年下半年的项目目标也很务实：先建立让 FLS 持续跟上 Rust 演进的人员、评审和更新节奏，并避免破坏安全关键用户已有的合规工作。

规范工作的难点不在第一版，而在持续维护：每六周都要判断哪些变化应进入哪份文本、由谁审查，以及如何与测试、实现、旧版本和认证证据对应。规范维护必须与 release train 同步。

Rust Project 当前的方向值得支持：语言与库团队保留各自领域的决定权，规范团队和编辑负责把决定变成一致文本，Rust Foundation 提供协调与资源。这样补的是语义文档与维护能力，不会平白再造一套语言设计流程。

为什么现在启动外部标准化，收益仍然不够

外部标准化有三种大致模式，它们的代价并不相同。

最温和的是下游快照：标准组织定期引用或整理 Rust Project 已发布的规范，不独立设计语言。它几乎不转移上游治理权，也最适合未来的采购和监管引用；代价是多一套版本号、同步流程和滞后窗口。

第二种是协同维护：Rust Project 与标准组织建立 liaison 或共同变更流程。它能让更多产业参与，但每个变化都要处理两边的程序与时间表。若权威边界写不清，Reference、FLS、外部标准和 rustc 之间可能出现冲突。

第三种是独立演进：外部组织可以接受、拒绝或修改语言特性，并把自己的文本视为最高规范。这会实质转移治理权，也最容易制造两种 Rust：项目发布的 Rust，以及标准文本定义的 Rust。

我反对 Rust 现在进入第三种模式，也看不到立刻启动第二种模式的必要。Rust 的主要实现、语言治理和发布仍高度一体化，现有 RFC、nightly 实验和稳定化流程能较快地把实现反馈送回设计。如果外部标准成为新特性的前置审批，试验成本会上升；如果它只在多年后追认上游，眼下得到的主要是版本同步负担。

标准化的价值必须由具体需求证明，不能靠“成熟语言都应该有标准”来证明。

一个可执行的结论

截至 2026 年，Rust 应优先完成三件事：让 Rust Project 持有的规范覆盖关键语义；让 Reference 与 FLS 的更新跟随 release，并逐步减少重复与冲突；把规范条目和实现测试、unsafe 规则、版本及认证证据连接起来。

现在不应把最终规范解释权交给可以独立于 Rust Project 演进的外部标准组织。

未来只要出现以下任一信号，就值得正式评估标准化，而不是自动标准化：

即使到了那时，我也会优先选择“以上游 Rust Project 为规范来源的下游快照”，而不是让外部标准文本反过来决定语言怎样演进。标准应当固化已经成熟的共同实践，不该抢在 nightly 前面设计 Rust。

这和上一篇的历史形成了自然呼应。Rust 能走到今天，靠的不是一次把未来写对，而是把试验与承诺分开：实验阶段可以根据证据修正方案，偏离既有决定时重新经过团队审批；进入 stable 之后再承担兼容责任。

规范应该把承诺写清楚。过早的外部治理型标准，可能把仍需试验的部分也提前冻结。

所以我的结论不是“Rust 永远不需要标准”，而是更具体的一句：Rust 现在需要完成自己的规范；等多实现、跨供应商合规或监管指称成为真实问题，再让标准化来解决那个问题。

参考资料